|
|
|
|
|
|
|
abstract the project tasks that apply only to architects. This, in turn, helps you focus on those tasks, should such duties be required of you. Without understanding this role, you risk not concentrating on the architecture elaboration process, which often leads to a faulty, pseudo-architecture. As a pseudo-architect in a traditional shop, a developer does what you might call detailed analysis, but it really is ad hoc design. Such developers take the list of functions and manipulate each one to communicate with another. Often, the code for some functions is hidden behind GUI control events (for example, Command1_Click) for the sake of convenience (ad-hoc spaghetti architecture). Such architecture makes it extremely difficult to trace application behavior back to the requirements and analysis models. |
|
|
|
|
|
|
|
|
Figure 2.2.
A service model. |
|
|
|
|
|
|
|
|
Object-oriented architects work with analystsand sometimes are the analyststo ensure that project team members can trace the names of business objects between the requirements and analysis models. Architects also work with designers and developers, but your main concern here is analysis. In traditional analysis, end users and managers assume that programmer-analysts have a nearly perfect understanding of the problem domain. This inevitably results in a decreased emphasis on analysis and increased emphasis on construction activities. Because the gap in knowledge between the users and developers isn't adequately addressed in the beginning, all the members and beneficiaries of the project teams (also known as stakeholders) experience levels of stress much higher than necessary as the project approaches its deadline. |
|
|
|
|
|
|
|
|
New Term: The problem domain is the business need being addressed by the proposed system under development. |
|
|
|
|
|
